Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9701/000052_owner-urn-ietf _Fri Jan 31 13:37:19 1997.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA05909 for urn-ietf-out; Fri, 31 Jan 1997 13:37:19 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA05903 for <[e-mail]>; Fri, 31 Jan 1997 13:37:14 -0500
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA27305  (mail destined for [e-mail]); Fri, 31 Jan 97 13:34:10 -0500
Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP)
          id <[e-mail]>; Fri, 31 Jan 1997 19:17:48 +0100
Date: Fri, 31 Jan 1997 19:17:46 +0100 (MET)
From: "Martin J. Duerst" <[e-mail]>
To: Daniel LaLiberte <[e-mail]>
Cc: "Ron Daniel Jr." <[e-mail]>, omar syed <[e-mail]>,
        URL mailing list <[e-mail]>, urn-ietf <[e-mail]>
Subject: Re: [URN] Re: Relative URLs and URNs
In-Reply-To: <[e-mail]>
Message-Id: <Pine.SUN.3.95q.970131181815.246R-100000@enoshima>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: "Martin J. Duerst" <[e-mail]>
Errors-To: [e-mail]

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

>  > Thus spoke Omar Syed:
>  > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
>  >
> Ron Daniel, Jr. writes:
>  > I think assumption 2 is in error. Clients that know the structure of
>  > a name in a particular namespace are likely to manipulate it.
>
> I agree.  Clients, of course, can do whatever they want (whatever they
> can get away with) anyway, but they have to be able to interpret the
> structure of an identifier in order to do as much processing of it on
> their own as they can.  Forcing clients (if that were possible) to
> always consult a remote server to process the whole identifier is a
> sure way to make the system unscalable.

Forcing to consult a *remote* server is a bad thing. On the other
hand, if we would require that a client *has to* understand anything
about the structure of certain URNs, that might also be too much
of a limitation.


> Ron Daniel, Jr. writes:
>  > This is the sort of problem I am running into now in our tests, where
>  > we have a bunch of HTML pages we are retroactively assigning URNs to.
>  > Since those pages have lots of relative links in them, we can either:
>  >   1) Make sure our new URNs reflect the same filesystem arrangement
>  >      as the pages do.
>  >   2) Modify the pages to make all the references absolute.
>  > Alternative 1 certainly is unattractive, since a major point of URNs is
>  > to provide independence from the filesystem organization du jour.
>
> First, identifiers (relative or not) may *reflect* a filesystem
> structure, but it is up to the server whether to look up an identifier
> in a filesystem, database, or pass it to a CGI program, for
> example.  So it is incorrect to assume filesystems specifically.

For what Ron is saying, the fact that it is the *filesystem* structure
is irrelevant. It could be any hierarchy. The main point is that
if you want to keep relative addressing and change the base, then
you have to keep the structure. This is a good thing with relative
URLs, because currently they mainly point to filesystems and
coordinated relocation of directory subtrees is an operation well
supported for filesystems. It's an operation that is much less
supported/common, and much less important, for other kinds of
things, for example for rote numberings and for conceptual hierarchies
(two of the things various people think URNs might be used for).


> But going beyond that, the identier may reflect a hierarchical
> structure (filesystem or not) and if you want that structure to be
> persistent, you have to arrange that old identifiers are redirected
> to the new identifiers, and the old identifiers are not reused for
> other purposes.

As far as I know, we mainly want the identifiers to be persistent.
Then if a bunch of identifiers stay persistent, their structure
will stay persistent (with the same sense of persistency as the
identifiers themselves).
For URNs (in contrast to URLs), keeping the structure when
moving from one namespace to another (or one part of a
hierarchy to another if there is a hierarchy) seems not to
be that important. In particular, for namespaces, the reason
to make a new namespace might very clearly be that you want
to have another structure. If you need the same structure,
you can always use the old names. For example, if you
take ISBN. It has structure: country/publisher/book/error code.
Now take Library of Congress numbers. If they had been happy
with the structure of ISBNs, they would have used ISBNs
(well, maybe historically, they were first).



Some more general thoughts:

One important question is whether one sees the world as primarily
hierarchical or not. File systems and the military are primarily
hierarchical, other systems are less so. Tim said in an earlier
message that throwing away the special meaning of "/" would mean
loosing generality. But this is only so if one sees the hierarchy
as the general case, and the non-hierarchical case as a one-level
hierarchy. From another viewpoint, everything is opaque, and the
hierarchical structure is just an internal affair.

Daniel, in other mails you have made references to efficiency
problems that can be alleviated by hierarchy. However, even
if an URN is completely opaque, there is no reason to have
efficiency problems. For example, the client could ask a
resolver close to it to help out, and this could go ask
another resolver if it can't deal with it. If you have
to split the load for a huge namespace, you can as well
split it on semantically meaningful boundaries as you
can split it on arbitrary boundaries (e.g. take the
two first letters of the string to decide which next
resolver to contact. For an example, in DNS currently
zones are related to ".". This creates big problems
because the .com-domain is too big. If we had a mechanism
to split such domains (I guess work is going on on such
things), then one of the obvious things would be to
split them on the last or the last two letters of the
label before .com.

Another idea is that something such as Java Applets are
part of a resolution scheme. For example, on a request for
an URN resolution, a browser recieves a (reference to) a
piece of code that it uses according to certain conventions.
Such an applet could for example do such things as say
"Hey, I know this namespace, and I know it has certain
conventions for hierarchies, and these hierarchies in
that case actually are connected to the way these things
are resolved, and I just helped resolve an URN
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^xyz
which is very similar to what I have to help resolve now, namely
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^pqr
so let's use (most of) the result of what I got for the
previous resolution.

Just some ideas.


Regards,    Martin.